<h2>Play with this demo</h2>
<p>
In this Activity, you can : 
<ul>
  <li> start a Loader and see there is no progress information. UI will be updated only when Loader fully completes;
  <li> cancel a started Loader ;
  <li> start a Loader, wait for completion, rotate the device and observe that UI is updated as expected (only when Loader fully completes);
  <li> if you have rotated the device (only once, see below), the loader is still complete : starting it again will get you instantly with the 
  result (full progress) and you must cancel the loader to restart it.
  <li> if you rotate twice the device, you will face a bug in Android SDK that crashes the loader, you get the feeling that the loader 
  is still present and fully complete but it crashed : you can start it again without any cancel operation.
  <li> no more memory leak, you can start as many Loaders as you want.
</ul>
</p>

<p>
Read below to learn more.
</p>

<h2>Basic Loader usage. </h2>

<p>
This Activity uses a simple Loader. <br>
</p>

<iframe src="loader_common.html" width="100%" height="400" frameborder="0">
<a href="loader_common.html">Here is a discussion on loader drawbacks.</a>
</iframe>

<p>
Nevertheless, Loaders are not very practical when it comes to Networking operations. We will demonstrate it in the last loader example, but first,
let's see how loaders work.
</p>

<h3>Memory leak issue</h3>

<p>
Loaders don't have any memory issue. 
</p>

<p>
Loaders provide a clear separation of "the asynchronous job to execute" (the Loaders) and "what has to be done when result is received" (LoaderCallbacks).
Thus, it doesn't encourage using an inner class for loaders as there is no need to update the UI from within the loaders. Loaders are designed to 
be written as separate classes or static inner classes.
If your loaders are provided as inner classes, you could have memory leak issues. But the loader framework prevents you from doing this, you will get
a <tt>RuntimeException</tt> is you try to do so.
<p/>

<p>Although, we should note that role separation is not very clear in the 
<a href="http://developer.android.com/reference/android/app/LoaderManager.LoaderCallbacks.html"/> LoaderManager.LoaderCallbacks</a> interface : 
the interface defines both management of loader life cycle methods (onCreateLoader and onLoaderReset) and a listener for Loader's 
computation result (onLoaderFinished).
</p>

<h3>Loaders and Activity life cycle</h3>

<p>
Generally, an activity will provide LoaderCallbacks either by using an inner class, or implementing
the LoaderCallbacks interface by itself. These callbacks are removed from the loader when activity is destroyed and re-associated to the loader 
when a new instance of the activity is created (after rotation for instance). 
</p>

<p>
In this demo, you will face a bug of the support library : after 2 rotations, you will receive an Exception : <tt>Called doRetain when not started: LoaderManager</tt>.
This will be logged in adb but can't be observed via the UI.
</p>

<h3>Progress and loaders </h3>
<p>
On this demo activity, you have to wait for the Loader to finish its task, it will then update the UI. There is no progress indication provided by 
loaders out of the box. We propose a work around for this in our next example.
</p>

<h3>Canceling a Loader</h3>

<p>
To cancel a loader is easy, you can ask the load manager to destroy the loader.
</p>


